# 하위 호환성

**하위 호환성**(ward Compatibility)은 소프트웨어, 시스템, 또는 기술 표준이 이전 버전과의 호환성을 유지하면서도 새로운 기능을 추가하거나 성능을 향상시킬 수 있는 능력을 의미합니다. 이는 사용자가 오래된 데이터, 애플리케이션, 또는 하드웨어를 새로운 환경에서도 그대로 사용할 수 있도록 보장하는 중요한 개념으로, 특히 엔터프라이즈 시스템, 운영체제, 데이터베이스, 그리고 소프트웨어 라이선스 정책에서 핵심적인 역할을 합니다.

하위 호환성은 기술 발전과 함께 사용자 경험의 연속성을 유지하는 데 기여하며, 업그레이드 비용과 리스크를 줄이는 데 큰 도움이 됩니다. 본 문서에서는 하위 호환성의 정의, 중요성, 소프트웨어 및 라이선스 측면에서의 적용 사례, 그리고 이를 유지하기 위한 전략을 다룹니다.

---

## 정의와 개념

하위 호환성은 새로운 시스템이나 소프트웨어가 **이전 버전에서 생성된 데이터나 프로그램을 그대로 실행하거나 처리할 수 있는 능력**을 말합니다. 예를 들어, Microsoft Word 2023이 Word 2003에서 작성된 `.doc` 파일을 열고 편집할 수 있다면, 이는 하위 호환성이 유지되고 있는 사례입니다.

반대로, **상위 호환성**(Forward Compatibility)은 이전 버전이 새로운 형식의 데이터를 처리할 수 있는 능력을 의미하지만, 일반적으로 하위 호환성이 더 중요하게 여겨집니다.

### 핵심 요소
- **데이터 형식 호환성**: 이전 버전의 파일 형식을 새 버전에서 읽고 쓸 수 있어야 함.
- **API 및 인터페이스 호환성**: 기존 프로그램이 새 시스템에서 변경 없이 동작해야 함.
- **라이선스 정책의 연속성**: 라이선스 조건이 새 버전에서도 기존 사용자의 권리를 침해하지 않아야 함.

---

## 소프트웨어에서의 하위 호환성

### 운영체제의 사례

대표적인 하위 호환성의 예는 **Windows 운영체제**입니다. Microsoft는 Windows 10 및 11에서 수십 년 전의 16비트 애플리케이션까지 실행할 수 있도록 호환성 모드를 제공합니다. 이는 기업들이 오래된 소프트웨어를 계속 사용할 수 있게 하여, 시스템 전환 비용을 절감합니다.

### 프로그래밍 언어와 라이브러리

프로그래밍 언어도 하위 호환성을 중요하게 다룹니다. 예를 들어:
- **Python 3**는 Python 2.x와 하위 호환성이 없습니다. 이는 큰 논란을 일으켰으며, 많은 라이브러리와 애플리케이션이 마이그레이션에 어려움을 겪었습니다.
- 반면, **Java**는 강력한 하위 호환성을 유지하여, JDK 8에서 작성된 코드가 JDK 17에서도 거의 변경 없이 실행됩니다.

이러한 차이는 사용자와 개발자 생태계에 큰 영향을 미칩니다. 호환성이 깨지면 유지보수 비용이 급증하고, 업그레이드가 지연될 수 있습니다.

---

## 라이선스 정책과 하위 호환성

소프트웨어 라이선스에서도 하위 호환성은 중요한 개념입니다. 이는 **기존 사용자가 새 버전의 라이선스 조건에 의해 불이익을 받지 않도록 보장**하는 것을 의미합니다.

### 라이선스의 연속성

예를 들어, 어떤 회사가 소프트웨어를 ** perpetual license**(영구 라이선스)로 판매하다가, 새 버전부터 **subscription model**(구독 모델)로 전환하는 경우, 기존 사용자는 계속해서 영구 라이선스의 혜택을 받아야 합니다. 이것이 바로 라이선스 정책의 하위 호환성입니다.

### 오픈소스 라이선스의 진화

오픈소스 라이선스에서도 하위 호환성 문제가 발생합니다. 예를 들어:
- **GPLv2**와 **GPLv3**는 서로 하위 호환되지 않습니다. GPLv2로 배포된 코드를 GPLv3 프로젝트에 포함하려면 명시적인 허가가 필요합니다.
- 반면, **MIT 라이선스**는 매우 유연하여, 다른 라이선스와의 호환성이 뛰어나며, 하위 호환성 측면에서 우수합니다.

이러한 라이선스 호환성은 프로젝트 통합, 커뮤니티 협업, 그리고 상용화 가능성에 직접적인 영향을 미칩니다.

---

## 하위 호환성을 유지하기 위한 전략

### 1. API 설계 시 호환성 고려
- 새로운 기능은 기존 API에 추가하는 방식으로 구현 (예: `function_v2()` 추가).
- 기존 함수의 시그니처나 동작을 변경하지 않음.
- **데프리케이션**(Deprecation)을 통해 점진적으로 기능을 폐지.

### 2. 마이그레이션 도구 제공
- 데이터 형식 변환기, 코드 리팩토링 도구 등을 제공하여 사용자의 전환 부담을 줄임.

### 3. 명확한 라이선스 정책 문서화
- 새 라이선스 도입 시 기존 사용자의 권리가 어떻게 보장되는지 명시.
- 라이선스 변경에 대한 사용자 동의 절차를 투명하게 운영.

### 4. 장기 지원(LTS) 버전 운영
- 기업용 소프트웨어의 경우, 장기적으로 유지보수되는 버전을 제공하여 안정성 보장.

---

## 관련 개념: 하위 호환성과 기술 부채

하위 호환성을 유지하는 것은 때때로 **기술 부채**(Technical Debt)를 증가시킬 수 있습니다. 오래된 기능이나 보안에 취약한 API를 계속 지원해야 하기 때문입니다. 따라서 개발팀은 **호환성 유지**와 **기술적 현대화** 사이에서 균형을 찾아야 합니다.

예를 들어, Internet Explorer의 오래된 렌더링 엔진은 Windows의 하위 호환성 정책으로 인해 오랫동안 유지되었으며, 이는 보안 취약점과 성능 저하의 원인이 되었습니다.

---

## 참고 자료 및 관련 문서

- [Microsoft Windows 호환성 문서](https://docs.microsoft.com/en-us/windows/win32/compatibility/)
- [GNU GPL 라이선스 비교](https://www.gnu.org/licenses/license-compatibility.html)
- [Semantic Versioning (SemVer) 표준](https://semver.org/)
- Martin Fowler, *Refactoring: Improving the Design of Existing Code*

---

하위 호환성은 단순한 기술적 요구를 넘어, **사용자 신뢰**, **생태계 안정성**, **비즈니스 지속성**과 직결되는 핵심 원칙입니다. 소프트웨어 개발 및 라이선스 정책 수립 시 이 개념을 철저히 고려하는 것은 장기적인 성공을 위한 필수 조건이라 할 수 있습니다.

## 파괴적 변경(Breaking Change)의 영향

하위 호환성 유지에 실패하여 발생하는 **파괴적 변경(Breaking Change)**은 기존 시스템의 동작을 중단시키거나 예기치 않은 오류를 유발하는 변경 사항을 의미합니다. 이는 단순히 기능의 변경을 넘어 생태계 전반에 다음과 같은 충격을 줍니다.

*   **의존성 지옥(Dependency Hell):** 특정 라이브러리의 파괴적 변경이 발생하면, 해당 라이브러리를 사용하는 수많은 상위 프로젝트들이 동시에 깨지게 되어 연쇄적인 수정 작업이 필요합니다.
*   **업그레이드 거부:** 업데이트 시 시스템 장애 리스크가 크다고 판단한 사용자들이 최신 버전의 보안 패치나 성능 개선 혜택을 포기하고 구버전에 머무르는 현상이 발생합니다.
*   **신뢰도 하락:** API의 일관성이 깨지면 개발자 커뮤니티 내에서 해당 플랫폼의 안정성에 대한 신뢰도가 급격히 하락합니다.

## 버전 관리 체계와 호환성 전략

현대 소프트웨어 공학에서는 **유의적 버전(Semantic Versioning, SemVer)** 체계를 통해 하위 호환성 보장 여부를 명시적으로 전달합니다. 버전 번호는 `MAJOR.MINOR.PATCH` 형식으로 구성됩니다.

### SemVer 버전별 호환성 기준
| 버전 구분 | 변경 내용 | 하위 호환성 여부 | 영향 및 대응 |
| :--- | :--- | :---: | :--- |
| **MAJOR** | API의 불호환 변경 (Breaking Changes) | **X** | 기존 코드가 작동하지 않을 수 있으며, 마이그레이션 필수 |
| **MINOR** | 하위 호환성을 유지하는 기능 추가 | **O** | 기존 기능은 유지되며, 새 기능을 선택적으로 사용 가능 |
| **PATCH** | 하위 호환성을 유지하는 버그 수정 | **O** | 기능 변경 없이 안정성 및 보안만 향상, 즉시 업데이트 권장 |

## 디자인 패턴을 활용한 호환성 구현

기술적 부채를 최소화하면서 하위 호환성을 유지하기 위해 소프트웨어 디자인 패턴을 적용할 수 있습니다.

### 어댑터 패턴(Adapter Pattern)의 적용
어댑터 패턴은 기존의 인터페이스를 변경하지 않고, 새로운 인터페이스로 변환해주는 중간 계층을 두어 호환성을 확보하는 방법입니다.

**[적용 전: 파괴적 변경 발생]**
기존 `getUser(id)` 함수가 `getUser(id, options)`로 변경되어, 기존 호출부에서 런타임 에러가 발생하거나 잘못된 값이 반환됨.
```javascript
// 구버전 호출 방식 (에러 발생 가능성)
const user = api.getUser(123); 
```

**[적용 후: 어댑터 패턴 도입]**
새로운 로직을 구현하되, 구버전 인터페이스를 유지하는 어댑터 함수를 제공하여 하위 호환성을 보장함.
```javascript
// 내부적으로는 최신 API를 사용하지만, 외부 인터페이스는 유지
function getUser(id) {
    // 구버전 호출을 최신 API 형식으로 변환하여 전달 (Adapter 역할)
    return api.getUser(id, { defaultOptions: true });
}

// 기존 호출 방식 그대로 사용 가능 (호환성 유지)
const user = getUser(123); 
```

## 호환성 관리의 생명주기

기능의 도입부터 제거까지는 사용자가 적응할 수 있는 충분한 유예 기간을 두는 단계적 프로세스가 필요합니다.

1.  **도입(Introduction):** 새로운 API나 기능이 추가됩니다.
2.  **권장되지 않음(Deprecated):** 해당 기능이 더 이상 권장되지 않음을 알리는 단계입니다. 기능은 여전히 작동하지만, 향후 제거될 예정임을 경고합니다.
    *   **실제 공지 예시:** 
        > "Warning: `api.fetchData()` is deprecated since v2.1.0 and will be removed in v3.0.0. Please use `api.request()` instead."
3.  **제거(Removed):** 메이저 버전 업데이트 시 해당 기능을 완전히 삭제합니다. 이 시점부터는 하위 호환성이 끊기며 파괴적 변경이 발생합니다.

## 점진적 마이그레이션과 EOL 전략

기술 부채를 해결하기 위해 무조건적인 호환성 유지보다는 전략적인 포기 시점을 결정하는 것이 중요합니다.

*   **점진적 마이그레이션(Incremental Migration):** 한 번에 모든 것을 바꾸는 것이 아니라, '구버전 지원 $\rightarrow$ 경고 메시지 출력 $\rightarrow$ 신규 버전 병행 운영 $\rightarrow$ 구버전 제거'의 단계를 거쳐 사용자를 유도합니다.
*   **서비스 종료(End-of-Life, EOL) 결정 기준:**
    *   **유지 비용의 임계점:** 구버전 지원을 위한 테스트 및 유지보수 비용이 신규 기능 개발 비용을 상회할 때.
    *   **보안 취약점:** 구버전의 구조적 결함으로 인해 최신 보안 표준을 적용할 수 없어 시스템 전체의 위험이 커질 때.
    *   **사용자 비율:** 전체 사용자 중 구버전 이용자 비율이 일정 수준(예: 5% 미만) 이하로 떨어졌을 때.